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DETAILED ACTION 

1 . This Office action is in response to the RCE filed on August 4, 2008. 

2. Claims 1-27 are pending. 

3. Claims 1, 10, and 19 have been amended. 

4. Applicant fails to address the objection to the abstract due to the use of an improper 
heading. Accordingly, this objection is maintained and fiirther explained hereinafter. 

5. Applicant fails to fully address the objection to the specification due to a typographical 
error. Accordingly, this objection is maintained and further explained hereinafter. 

6. The 35 U.S.C. § 112, second paragraph, rejections of Claims 1-27 are maintained in view 
of Applicant's arguments and further explained hereinafter. 

7. The 35 U.S.C. § 101 rejections of Claims 10-18 are withdrawn in view of Applicant's 
amendments to the claims. 



Continued Examination Under 37 CFR 1.114 
8. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible 
for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been 
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 
1.114. Applicant's submission filed on August 4, 2008 has been entered. 
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Response to Amendment 
Specification 

9. The abstract of the disclosure is objected to because the heading of the abstract should be 
"Abstract" or "Abstract of the Disclosure." See 37 CFR § 1.72(b). 

10. The disclosure is objected to because of the following informalities: All instances of "jar" 
should be changed to uppercase in paragraph [0033]. 

Appropriate correction is required. 

Claim Rejections - 35 USC § 112 

1 1 . The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

12. Claims 1-27 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

Claims 1, 3-6, 9, 10, 12-15, 18, 19, 21-24, and 27 contain the trademark or trade name 
JAVA. When a trademark or trade name is used in a claim as a limitation to identify or describe 
a particular material or product, the claim does not comply with the requirements of the 35 
U.S.C. 1 12, second paragraph. Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim 
scope is imcertain since the trademark or trade name cannot be used properly to identify any 
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particular material or product. A trademark or trade name is used to identify a source of goods, 
and not the goods themselves. Thus, the use of a trademark or trade name in a claim to identify 
or describe a material or product (in the present case, a specific programming language) would 
not only render a claim indefinite, but would also constitute an improper use of the trademark or 
trade name. 

Claims 2, 7, and 8 depend on Claim 1 and, therefore, suffer the same deficiency as 
Claim 1. 

Claims 11, 16, and 17 depend on Claim 10 and, therefore, suffer the same deficiency as 
Claim 10. 

Claims 20, 25, and 26 depend on Claim 19 and, therefore, suffer the same deficiency as 
Claim 19. 

Claim Rejections - 35 USC § 103 

13. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

14. Claims 1-6, 8, 10-15, 17, 19-24, and 26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over US 6,986,132 (hereinafter "Schwabe") in view of US 6,430,564 
(hereinafter "Judge"). 
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As per Claim 1, Schwabe discloses: 

- receiving source input corresponding to a first release of Java™ byte code and target 
input corresponding to a second release of the Java™ byte code (see Figure 20A: 1540 and 
1550); 

- transforming the source input into a first list that contains Java™ class names 
associated with the first release of Java™ byte code, and the target input into a second list 
containing Java™ class names associated with the second release of the Java™ byte code (see 
Figure 20A: 1535 and 1545; Column 14: 14-15, "An API definition file defines the context of a 
binary file in relationship to other referenced binary files. "); 

finding matching class names between the first list and the second list, and loading 
classes corresponding to the matching class names (see Figure 2; Column 4: 1-10, "In the JVM, 
the loading step retrieves the class file representing the desired class. "; Column 5: 23-27, 
"When the binary file 60 is referenced by an application executing on a virtual machine 65, a 
loader 70 loads the binary file 60. A verifier 75 verifies the binary file 60 at some point prior to 
execution by an interpreter 80. "; Column 25: 44-48, "If the set of classes and interfaces defined 
in the old API definition file is not found in the new API definition file ... "); and 

comparing the loaded classes to identify APIs that have been modified between the 
first release of Java™ byte code and the second release of the Java™ byte code, wherein an API 
has not been modified in case that it maintains a same name, parameter order, parameter types 
and return types in both the first release of the Java™ byte code and the second release of the 
Java™ byte code (see Figure 2; Column 25: 50-53, "... the class and interface attributes are 
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compared to the attributes of the same class or interface in the new package. The attributes may 
include the name, flags, number of fields and number of methods. "; Column 26: 1-10, "At 1650, 
for each field in the old package, the attributes are compared to the same field in the new 
package. The attributes may include the name.fiags and type. " and "At 1655, for each method 
in the old package, the attributes are compared to the same method in the new package. The 
attributes may include the name, flags and signature. "). 
However, Schwabe does not disclose: 

- removing the matching class names from the first list and the second list after the 
comparing, wherein any class names remaining in the first list represent APIs that have been 
removed for the second release of the Java^^ byte code, and wherein any class names remaining 
in the second list represent APIs that have been added for the second release of the Java™ byte 
code. 

Judge discloses: 



- removing the matching class names from the first list and the second list after the 
comparing, wherein any class names remaining in the first list represent APIs that have been 
removed for the second release of the Java™ byte code, and wherein any class names remaining 
in the second list represent APIs that have been added for the second release of the Java™ byte 
code (see Column 4: 63-67 through Column 5: 1-5, "Method unloadDataClass unloads a data 
class by the name of'dataName" by removing the data class object and all instances of the data 
class object from the data cache 54. Upon removal of a data class object from the data cache 54, 
the name of the data class "dataName" is also removed from the data class list 47 maintained by 
Data Manager 48. "). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Judge into the teaching of Schwabe to include 
removing the matching class names from the first list and the second list after the comparing, 
wherein any class names remaining in the first list represent APIs that have been removed for the 
second release of the Java™ byte code, and wherein any class names remaining in the second list 
represent APIs that have been added for the second release of the Java™ byte code. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
determine differences between two data lists. 

As per Claim 2, the rejection of Claim 1 is incorporated; and Schwabe further discloses: 

- outputting a report identifying at least one of the APIs that have been modified, the 
APIs that have been removed and the APIs that have been added (see Column 25: 44-67 through 
Column 26: 1-10, "...a verification error is indicated. "). 

As per Claim 3, the rejection of Claim 1 is incorporated; and Schwabe further discloses: 

- wherein the loading step comprises loading at least one Java™ class of the first 
release of Java™ byte code and at least one Java™ class of the second release of the Java™ byte 
code (see Column 4: 1-10, "In the JVM, the loading step retrieves the class file representing the 

desired class. "). 

As per Claim 4, the rejection of Claim 3 is incorporated; and Schwabe further discloses: 
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listing methods of the at least one Java™ class of the first release of Java™ byte code 
in the first list, and listing methods of the at least one Java™ class of the second release of the 
Java™ byte code in the second list (see Column 26: 6-10, "At 1655, for each method in the old 
package, the attributes are compared to the same method in the new package. The attributes may 
include the name, flags and signature. "). 

As per Claim 5, the rejection of Claim 4 is incorporated; and Schwabe fiirther discloses: 
- wherein the comparing step comprises comparing the methods in the first hst to the 

methods in the second list to identify APIs that have been modified between the first release of 
Java™ byte code and the second release of the Java^M byte code (see Column 25: 50-53, "... the 
class and interface attributes are compared to the attributes of the same class or interface in the 
new package. The attributes may include the name, flags, number of fields and number of 
methods. "). 

As per Claim 6, the rejection of Claim 5 is incorporated; however, Schwabe does not 
disclose: 

wherein the removing step comprises removing, from the first list and the second list, 
any methods in the first list that are identical to methods in the second list based on the 
comparison, wherein any methods remaining in the first list after the removing represent APIs 
that have been removed for the second release of the Java™ byte code, and wherein any methods 
remaining in the second list after the removing represent APIs that have been added for the 
second release of the Java™ byte code. 
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Judge discloses: 

- wherein the removing step comprises removing, from the first list and the second list, 
any methods in the first list that are identical to methods in the second list based on the 
comparison, wherein any methods remaining in the first list after the removing represent APIs 
that have been removed for the second release of the Java™ hytc code, and wherein any methods 
remaining in the second list after the removing represent APIs that have been added for the 
second release of the Java™ byte code (see Column 4: 63-67 through Column 5: 1-5, "Method 
unloadDataClass unloads a data class by the name of'dataName" by removing the data class 
object and all instances of the data class object from the data cache 54. Upon removal of a data 
class object from the data cache 54, the name of the data class "dataName" is also removed from 
the data class list 47 maintained by Data Manager 48. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Judge into the teaching of Schwabe to include 
wherein the removing step comprises removing, from the first list and the second Ust, any 
methods in the first list that are identical to methods in the second list based on the comparison, 
wherein any methods remaining in the first list after the removing represent APIs that have been 
removed for the second release of the Java^^ byte code, and wherein any methods remaining in 
the second list after the removing represent APIs that have been added for the second release of 
the Java™ byte code. The modification would be obvious because one of ordinary skill in the art 
would be motivated to determine differences between two data lists. 

As per Claim 8, the rejection of Claim 1 is incorporated; and Schwabe further discloses: 
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- wherein the source input and the target input comprise a list of classes (see Column 
22: 56-58, "A library or applet package (herein referred to as a binary file) is received (1460) 
..."). 

Claims 10-15 and 17 are system claims corresponding to the method claims above 
(Claims 1-6 and 8) and, therefore, are rejected for the same reasons set forth in the rejections of 
Claims 1-6 and 8. 

Claims 19-24 and 26 are program product claims corresponding to the method claims 
above (Claims 1-6 and 8) and, therefore, are rejected for the same reasons set forth in the 
rejections of Claims 1-6 and 8. 

15. Claims 7, 9, 16, 18, 25, and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Schwabe in view of Judge as applied to Claims 1,10, and 19 above, and further in view of 
US 6,385,722 (hereinafter "Connelly"). 

As per Claim 7, the rejection of Claim 1 is incorporated; however, Schwabe and Judge 
do not disclose: 

- wherein the source input and the target input comprise JAR files. 
Connellv discloses: 

- wherein the source input and the target input comprise JAR files (see Column 1: 14- 
17, "Software vendors typically ship their products as a set of shared libraries, such as libraries 
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written in the Java™ object-oriented programming language and packaged as a conventional 
shared library file called a JAR file. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Connelly into the teaching of Schwabe to 
include wherein the source input and the target input comprise JAR files. The modification 
would be obvious because one of ordinary skill in the art would be motivated to easily and 
efficiently share and use these library files (see Connelly - Column 1: 17-20). 

Claims 16 and 25 are rejected for the same reason set forth in the rejection of Claim 7. 

As per Claim 9, the rejection of Claim 1 is incorporated; however, Schwabe and Judge 
do not disclose: 

inputting class paths common to the first release of Java™ byte code and the second 
release of the Java™ byte code. 
Connelly discloses: 

- inputting class paths common to the first release of Java™ byte code and the second 
release of the Java™ byte code (see Column 7: 46-48, "... the class java.net.URLClassLoader is 
used as class loader 122 to load classes and resources from a class path of JAR files and 
directory URLs. "). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Connellv into the teaching of Schwabe to 
include inputting class paths common to the first release of Java™ byte code and the second 
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release of the Java™ byte code. The modification would be obvious because one of ordinary 
skill in the art would be motivated to access the parts of shared libraries (see Connelly - Column 
1: 31-34). 

Claims 18 and 27 are rejected for the same reason set forth in the rejection of Claim 9. 

Response to Arguments 

16. Applicant's arguments filed on August 4, 2008 have been fiiUy considered, but they are 
not persuasive. 

In the Remarks, Applicant argues: 

a) The Office has asserted that claims 1-27 are indefinite for failing to particularly point out 
and distinctly claim the subject matter which Applicant regards as the invention. Specifically, the 
Office objects to use of the word "JAVA" in the claims. Applicant respectfully submits that 
". . .The presence of a trademark or trade name in a claim is not, per se, improper under 35 U.S.C. 
§ 1 12, second paragraph. . ." MPEP 2173.05(u). To this extent, the MPEP does not strictly forbid 
the use of trademarks in the claims, but rather only those which are not ".. .sufficiently precise 
and definite." MPEP §608.01(v). Applicant asserts that in the word JAVA, in the context of the 
claimed invention, refers to an environment within which the invention functions and/or a 
framework that defines the structure of the constructs of the invention, and not simply a source 
of goods. To this extent, the term JAVA has a definite meaning, and its use in the claims is 
permitted. 
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Examiner's response: 

a) Examiner disagrees. With respect to the Applicant's assertion that the trademark JAVA 
has a definite meaning, and its use in the claims is permitted, the Examiner respectfully submits 
the relevant portions of MPEP §§ 608.01(v) and 2173.05(u) with emphasis added for purposes of 

convenience in discussion and illustration: 



MPEP § 608.01(y) Trademarks and Names Used in Trade 

I. TRADEMARKS 

The relationship between a trademark and the product it identifies is 
sometimes indefinite, uncertain, and arbitrary. The formula or characteristics 
of the product may change from time to time and yet it may continue to be sold 
under the same trademark. In patent specifications, every element or ingredient 
of the product should be set forth in positive, exact, intelligible language, so 
that there will be no uncertainty as to what is meant. Arbitrary trademarks 
which are liable to mean different things at the pleasure of manufacturers do not 
constitute such language. Ex Parte Kattwinkle, 12 USPQ 1 1 (Bd. App. 1931). 



MPEP § 2173.05(u) Trademarks or Trade Names in a Claim 
The presence of a trademark or trade name in a claim Is not, perse, 
improper under 35 U.S.C. 112, second paragraph, but the claim should be 
carefully analyzed to determine how the mark or name is used in the claim. 
It is important to recognize that a trademark or trade name is used to 
identify a source of goods, and not the goods themselves. Thus a trademark 
or trade name does not identify or describe the goods associated with the 
trademark or trade name. See definitions of trademark and trade name in 
MPEP § 608.01(v). A list of some trademarks is found in Appendix I. 

If the trademark or trade name is used in a claim as a limitation to identify 
or describe a particular material or product, the claim does not comply with 
the requirements of the 35 U.S.C. 112, second paragraph. Ex parte Simpson, 
218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the 
trademark or trade name cannot be used properly to identify any particular 
material or product. In fact, the value of a trademark would be lost to the extent 
that it became descriptive of a product, rather than used as an identification of a 
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source or origin of a product. Thus, the use of a trademark or trade name in a 
claim to identify or describe a material or product would not only render a claim 
indefinite, but would also constitute an improper use of the trademark or trade 
name. 

If a trademark or trade name appears in a claim and is not intended as a limitation 
in the claim, the question of why it is in the claim should be addressed. Does its 
presence in the claim cause confiision as to the scope of the claim? If so, the claim 
should be rejected under 35 U.S.C. 1 12, second paragraph. 

According to MPEP § 2173.05(u) provided above and as previously pointed out in the 
Final Rejection (mailed on 05/02/2008) and further clarified hereinafter, the Examiner 
respectfully submits that if the trademark or trade name is used in a claim as a limitation to 
identify or describe a particular material or product, the claim does not comply with the 
requirements of the 35 U.S.C. 1 12, second paragraph. Id. The trademark JAVA is used in the 
claims to describe a particular programming language. It refers to a specific product that is 
proprietary to Sun Microsystems. When a trademark or trade name is used in a claim as a 
limitation to identify or describe a particular material or product, the claim does not comply with 
the requirements of the 35 U.S.C. 1 12, second paragraph. Ex parte Simpson, 218 USPQ 1020 
(Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used 
properly to identify any particular material or product. Id. A trademark or trade name is used to 
identify a source of goods, and not the goods themselves. Thus, the use of a trademark or trade 
name in a claim to identify or describe a material or product would not only render a claim 
indefinite, but would also constitute an improper use of the trademark or trade name. Id. 
Furthermore, MPEP § 608.01(v) provides guidelines on the use of trademarks in patent 
specifications and thus, does not pertain to the use of trademarks in the claims. 
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Therefore, in view of the foregoing analysis, the rejections made under 35 U.S.C. § 1 12, 
second paragraph, with respect to Claims 1-27 are proper and therefore, maintained. 

In the Remarks, Applicant argues: 

b) With regard to the 35 U.S.C. § 103(a) rejections over Schwabe in view of Judge, 
Applicant asserts that the references cited by the Office do not teach or suggest each and every 
feature of the claimed invention. For example, with respect to newly amended independent 
claims 1,10 and 19, Applicant submits that the cited references fail to teach or suggest 
comparing the loaded classes to identify APIs that have been modified between the first release 
of Java byte code and the second release of the Java byte code, wherein an API has not been 
modified in case that it maintains a same name, parameter order, parameter types and return 
types in both the first release of the Java byte code and the second release of the Java byte code. 
Instead, in the passage of Schwabe cited by the Office, it is the API definition files that are 
compared and not loaded classes. Rather, as stated elsewhere herein, Schwabe teaches against 
comparing of loaded classes, but only compares the definition files. Furthermore, neither of the 
references teaches or suggests the exact comparison of the claimed invention. 

Examiner's response: 

b) Examiner disagrees. With respect to the Applicant's assertion that the cited references 
fail to teach or suggest comparing the loaded classes to identify APIs that have been modified 
between the first release of Java byte code and the second release of the Java byte code, wherein 
an API has not been modified in case that it maintains a same name, parameter order, parameter 
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types and return types in both the first release of the Java byte code and the second release of the 
Java byte code, the Examiner respectfully submits that Schwabe clearly discloses "comparing the 
loaded classes to identify APIs that have been modified between the first release of Java byte 
code and the second release of the Java byte code, wherein an API has not been modified in case 
that it maintains a same name, parameter order, parameter types and retum types in both the first 
release of the Java byte code and the second release of the Java byte code" (see Figure 2; 
Column 25: 50-53, "... the class and interface attributes are compared to the attributes of the 
same class or interface in the new package. The attributes may include the name, flags, number 
of fields and number of methods. "; Column 26: 1-10, "At 1650, for each field in the old package, 
the attributes are compared to the same field in the new package. The attributes may include the 
name, flags and type. " and "At 1655, for each method in the old package, the attributes are 
compared to the same method in the new package. The attributes may include the name, flags 
and signature. "). 

In the Remarks, Applicant argues: 

c) With fiirther respect to independent claims 1,10 and 19, Applicant continues to submit 
that the cited references fail to teach or suggest finding matching class names between the first 
list and the second list, and loading classes corresponding to the matching class names. Rather, 
the passages in Schwabe refer to different fimctions of Schwabe that are completely unrelated. 
The first passage of Schwabe cited by the Office mentions comparing the set of classes and 
interfaces in an old API definition file with those in a new API definition file. The second 
passage references loading of class files. However, the passages in Schwabe cited by the Office 
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do not disclose that the loading of the class files that are loaded are of class files that are derived 

from the matching. In fact, Schwabe does not even indicate that the class files that are loaded are 

taken from its API definition files. Rather, Schwabe expressly teaches that 

. . .verification does not continue beyond an API definition file. This differs from 
tj^ical verification methods that continue the verification process into an 
implementation of the API definition file. Col. 14, lines 10-13. 

To this extent, Schwabe teaches against the loading of classes based on results from an API 

definition file verification in its verification process. This is in confrast to the claimed invention 

in which the classes that are loaded correspond to the matching class names between the first list 

and the second list. For the above reasons, the separate comparing and loading of Schwabe does 

not teach or suggest the loading based on the matching of the claimed invention. Judge does not 

cure this deficiency. 

Examiner's response: 

c) Examiner disagrees. Applicant's arguments are not persuasive for at least the following 
reasons: 

First, with respect to the Applicant's assertion that the cited passages in Schwabe refer to 
different functions that are completely unrelated, as previously pointed out in the Final Rejection 
(mailed on 05/02/2008) and further clarified hereinafter, the Examiner respectfully submits that, 
in the drawing figure and passages cited by the Examiner, Schwabe describes class loading and 
verification in the JVM, which is well-known to those of ordinary skill in the art. In the JVM, a 
loader loads a class file prior to a verifier verifies it. Thus, one of ordinary skill in the art would 
readily comprehend that loading of class files occurs first in the JVM and then, the verifier 
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verifies the loaded class files. Therefore, the loading process and the verification process are 
related processes in the JVM. 

Second, with respect to the Applicant's assertion that Schwabe does not teach nor suggest 
the loading based on the matching of the claimed invention, as previously pointed out in the 
Final Rejection (mailed on 05/02/2008) and further clarified hereinafter, the Examiner 
respectfiiUy submits that Schwabe clearly discloses "loading classes corresponding to the 
matching class names" (see Figure 2; Column 4: 1-10, "In the JVM, the loading step retrieves 
the class file representing the desired class. "; Column 5: 23-27, "When the binary file 60 is 
referenced by an application executing on a virtual machine 65, a loader 70 loads the binary file 
60. A verifier 75 verifies the binary file 60 at some point prior to execution by an interpreter 
80. "). Note that, as clarified hereinabove, the verification process occurs after a class file is 
loaded. Thus, after matching the set of classes and interfaces between the old API definition file 
and the new API definition file occurs, the matching set of classes and interfaces are loaded to be 
verified by the verifier. 

Therefore, for at least the reasons set forth above, the rejections made under 35 U.S. C. § 
103(a) with respect to Claims 1,10, and 19 are proper and therefore, maintained. 

Conclusion 

17. Any inquiry concerning this communication or earlier communications from the 
Examiner should be directed to Qing Chen whose telephone number is 571-270-1071. The 
Examiner can normally be reached on Monday through Thursday from 7:30 AM to 4:00 PM. 
The Examiner can also be reached on alternate Fridays. 
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If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's 
supervisor, Wei Zhen, can be reached on 571-272-3708. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Any inquiry of a general nature or relating to the status of this apphcation or proceeding 
should be directed to the TC 2100 Group receptionist whose telephone number is 571-272-2100. 

Information regarding the status of an apphcation may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpubhshed 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Elecfronic Business Center (EBC) at 866-217-9197 (toll-free). 

/Q. C.I 

Examiner, Art Unit 2191 



/Wei Y Zhen/ 

Supervisory Patent Examiner, Art Unit 2191 



